Rethinking the Microworld Idea

In this paper we reflect on the meaning and evolution of the microworld idea. We point out a crucial distinction between user manipulation and modification at three distinct but mutually dependent levels — the interface, superstructural and platform levels. We exploit a case study of two 8-year-old girls playing and rebuilding a simple video game, to argue for the importance of ease of interplay between these levels. We reflect on the ways in which newly-created alternatives to textual forms of representation are redefining the utility and power of microworlds, and offering advantages (as well as disadvantages) for mathematical learning in the sense of understanding inference and mechanism — how things work and why. What is a microworld? The microworld idea is about three decades old, time enough for the idea to have become debased. Like 'constructivism', it is a Good Thing, a designation to which the creators of even the dullest and least instructive software often aspire. Despite this, the idea of a microworld as a place where the student, though playing, may stumble over and then ponder important inspirations and concepts, is one that nicely captures at least one crucial organising feature of the original idea. The pedigree of the concept is indicative of the inspiration behind it: Hoyles (1993) charts its evolution from an AI description of a simple and constrained aspect of the real world to part of a knowledge domain which is changing and growing and which has epistemological significance. Laurie Edwards's (1995) extensive review of microworlds similarly stresses knowledge as a central element, and makes a useful distinction between structural and functional views of the idea. The former view prioritises the idea of a microworld as a concrete embodiment of a mathematical structure that is extensible (so tools and objects can be combined to build new ones), but also transparent (so its workings are visible) and rich in different representations. The latter view prioritises features of the microworld that become apparent in use, where learners are expected to explore and build, learn from feedback while involved in the iterative design of long term projects — rather than in trying to master decontextualised knowledge fragments (following diSessa, 1985). Clearly the structural and functional views of a microworld are not antithetical, and microworld designers are at pains to try to keep both in mind, most usefully by focussing on the activity structures the microworld is designed to offer, where students construct their own meanings, representations and expressions. It is this facet which, incidentally, provides researchers and teachers with such a helpful 'window' onto the evolution of learners' thinking, and which we have discussed in depth in our book (Noss and Hoyles, 1996). Thus microworlds are environments where people can explore and learn from what they receive back from the computer in return for their exploration. It follows, therefore, that a microworld has its own set of tools and operations that are open for inspection and change. In this sense, learners themselves are in the position simultaneously of user and designer (interestingly, this is true for computer scientists too — any good programming language casts the programmer in the role of language designer, as they create tools and objects for the solution of problems; see Abelson and Sussman, 1985). These twin roles for the learner lead directly to the idea of constructionism, which argues that effective learning 'will not come from finding better ways for the teacher to instruct but from giving the learner better opportunities to construct (Papert, 1991, p 3). We view constructionism as giving the learner opportunities to build her own physical, virtual and mental knowledge structures. It is this belief, that building things is a locus of significant educational change, that drove the initial rationale for microworlds and provides a crucial organising distinction between systems which put the child in the role of builder and thinker, and those which place him or her in the role of listener or receiver. To build physical or mental structures requires tools, and a means of employing them. What should these tools be and how are they deployed and combined? To what extent can tools be recast by learners? This is the technical face of a thorny question that we want to explore in this paper, a question which has troubled many microworld designers: to put it bluntly, does the constructionist ethic (at least in so far as it entails computer use) involve the learner in programming? There is little doubt that it originally did: in the past, the creation and reconstruction of executable actions were precisely what characterised programming, the construction of the bits and pieces of (textual) code which produced an effect on the screen (or in the case of Logo, on the turtle's behaviour). Slowly, as the idea of programming evolved and as what was possible and accessible on the screen developed microworlds — even Logo microworlds — were designed which expressly excluded the learner from delving down into the core language. In fact, Edwards argued that a Logo microworld did not necessarily involve Logo programming, modification of Logo code or interaction with Logo at all (Edwards 1995 p. 134, emphasis in original). In these cases, the learner only operated with the microworld tools, which may have been written in Logo but were not open for inspection (examples of such microworlds have been designed by Thompson, 1992, Edwards, 1991 and more recently by Kalas, 1997, Turcsányi-Szabó, 1999). This issue of the availability of programming is not merely of Talmudic importance. After all, programming is the prototypical tool for the constructionist vision, and a microworld without programming runs the risk of avoiding just the thing that gives a microworld its power. If children cannot program at all, how can they build the tools that they need to model and come to understand a mathematical idea? More crucially, how do they know that models can evolve and change? In our view, the key question is: Are students still in the position to build new tools if they have no access to or appreciation of programming? 1 Actually, such attempts were often accompanied by descriptions and reports which stated that the learner could in fact interact with the code and modify the microworld: in our experience hardly any ever did unless very specific help and guidance to do so was on hand. Our answer to date has been consistently in the negative, although the microworlds we have developed have tended over the years to become more focussed on mathematical structures in order to contain the problems of lack of programming expertise (see for example, Hoyles and Noss, 1987a). Yet in the years since the microworld idea has taken hold, it is precisely this point — the idea of children programming computers — which has become so problematic. For one thing, there are practical objections — programming takes too much time in what is already a crowded mathematics curriculum; programming is too hard (for teachers as well as students); programming diverts attention from the underlying knowledge goals. If the last point is true then there clearly is no place for programming, at least within an explicitly educational setting (like school) where the objective is to learn mathematics, say — not programming. But at a deeper level, some have questioned whether the objectives we have outlined for programming are still only attainable in this way. In this paper, we ask whether it still makes sense to insist on programmability as a vehicle for creativity and constructionist learning. There is an interesting evolution here; of developments in programming languages, the scope of what is possible, and the slow but sure increase in our knowledge base of how children learn within microworlds. We do not intend to trace these developments in this paper (many are available in diSessa, Hoyles and Noss, 1995). Rather we will re-examine our own work, as a way to assess the extent to which both the microworld idea and the meaning of programming have evolved. The symbolic core of a mathematical microworld In an early paper of ours (Hoyles and Noss, 1987b), we critiqued a promising and certainly useful program of its time — let's call it software X. When software X is run it displays sequences of numbers that children are asked to inspect, spot a pattern and generalise. We pointed out that: There is no opportunity [with X] to develop a constructive approach to the formalisation of the program; the pupils cannot build up the symbolic language for themselves, attach meaning to the specific parts of the syntax or learn through the computer feedback the effects of modification or extensions of the symbolic form. Try to generate a geometric progression within the available framework of the program and it will be clear what the distinction is. (ibid., p. 590-591). The details of X are irrelevant here. Rereading our critical remark more than a decade later, we are struck by our insistence that the learner ought to be able to do the unexpected, to attain expressive power over tasks which the designer had not preconceived — a demanding criterion, which assumes a great deal about the learning culture and activity structures of the learners' environment. From another, more specifically mathematical perspective, we were unhappy that the mathematical structures which underpinned the sequences under investigation were invisible; there was no access to the code so users were restricted to searching for patterns in the output data rather than within the processes by which they were constructed. This point we still regard as central to learning mathematics. All too often children (at least in UK) are diverted by surface relationships between numbers and ignore the structural, mathematical reasons why they may or may not be related (Healy and Hoyles, 1999). Thus far we think we were right: we remain convinced of the constructionist ethic, and the extent to which programmability of one kind or another is an essential precondition for it. Building up pieces of knowledge on the screen as external representations for knowledge structures necessitates some means of expressing the ideas under construction and that still, by our definition at least, means programming. We are relieved to see that we recognised even then, the importance of serendipitous learning, of finding ways to open rather than close down alternative learning paths, interesting avenues or activities that the designer had not intended. Clearly this aspiration raises challenges for the teacher, (which we have discussed in Noss and Hoyles, 1996) and we recognise that it is precisely this aspect of openness that leads many, if not most, software designers to try to do quite the opposite. There is, however, one interesting assumption behind our early work, which is evident in the quotation above. It is the identification of formalisation with construction, between the symbolic language and the mathematical ideas embedded in the microworld. Our statement rested on an assumption that the expression of complex ideas and its communication to a computer in a program necessitated formal, rigorous collections of symbols in the form of textual strings. This, we thought, was at the heart of the microworld's utility for learning and we were unashamed on this point. Regarding software X, we said, [It] fails as a microworld because it does not offer an algorithmic representation of the concept to be explored. It thus does not provide the 'hooks' to the power of the language that, in our view, provides the essential interplay between mathematical concepts and their formalization. (ibid., p. 591) And some ten years later, we were still saying in Windows on Mathematical Meanings: ... the fundamental facet of programming environments is the imperative of formalization inherent within them. We will provide many examples of the critical role played by the linguistic formalization of programming in aiding learners' mathematical expression and in developing their mathematical understandings. (Noss and Hoyles, 1996; p. 62, emphasis added). Before we criticise (with considerable hindsight) the assumptions behind this position, we should try to defend ourselves. In Windows we give a number of examples of the critical role played by the linguistic formalisation of programming in aiding learners' mathematical expression. Unsurprisingly, these privileged the textual side of programming. But we were also keen to find ways to forge links between textual and other representations. It may help if we describe the examples, one sentence each. They were: a classical microworld for exploring non-Euclidean geometry, employing an object-oriented version of Logo; a conventional application of Logo as a cumulative device for exploring convergence and divergence of series; a new way of representing functional relationships among terms of a sequence; an unexpectedly powerful solution to an old problem, using a massively parallel version of Logo (StarLogo); and a Logo approach to the mathematics of banking, which illustrated programming as a means to unify apparently disparate pieces of banking knowledge. Looking back on these examples, we remain convinced that student-accessible programming is an essential prerequisite for expressivity (in addition to all the Logo literature here, see also the work on Boxer, diSessa and Abelson, 1986). In one example however, programming was given a slightly altered role, namely to serve as the symbolic representation of a mathematical function as well as the glue that bound all the representational modes together. We have considered this example in much detail elsewhere (see, Noss, Healy and Hoyles, 1997). Here we simply summarise the main points relevant to the idea of a microworld. An example of a microworld We built a microworld, Mathsticks, (written in Microworlds Logo) which involves the learner in constructing sequences of objects on the screen, and manipulating them directly. The key interesting feature of this program is that while the user is manipulating objects directly, there is also graphical feedback as to the results of their actions and a visible (conventional, Logo) program constructed to provide a formal representation of what has been done. By exploiting the relative advantages of direct manipulation and text-based programming, we aimed therefore to construct an environment in which users would learn by linking their actions with the graphical or the symbolic representations — both representations were consistently available. We have noted in the past the problems that children have with maintaining a connection in Logo programming between the symbolic commands and their visual effects (Hoyles and Sutherland, 1989). In terms of elementary geometry, Turtle Math has gone a long way to overcome this problem through its maintenance of a close correspondence between representations and the bidirectionality between the different modes — that is the student can move the mouse and the Logo commands are created automatically (see Clements & Sarama, 1995, Clements, Battista, Sarama, Swaminathan, 1996). We tried to build something similar in our Mathsticks microworld. The main feature of the microworld was that purpose-built tools were designed to simulate the arrangement of matches in a sequence (see Figure 1), with the mathematical goal that students would come to appreciate number patterns as functional relationships. An example screen from the Mathsticks microworld Here we simply summarise our agenda and findings. First the students would be asked to build by direct manipulation of the screen matches, a model of how they saw a given term in a sequence of matches. For example in Figure 1, the students had constructed the fifth term of a sequence of squares. Through this process of construction, we anticipated that students would come to notice the structure of the given term in itself and in relation to others; they would begin to see the particular case as an instance of the general. Our expectation stemmed from two sources: firstly because their mental image of the task could be reflected in their actions in the microworld (for example picking up and putting together the matchstick icons shown on the top right of the screen), and in the rhythm of their pointing and clicking; and secondly because it could be realised simultaneously in symbols (programming code) appearing in the box labelled 'history' and visually as an array of graphical objects. (For details of how the different images the students held of the task, see Healy and Hoyles, 1999). But Logo did not only serve the role of a symbolic representation of the mathematics involved. We encouraged the students to write a general Logo procedure that could be used to build any term of the sequence. This, we hoped, would force the distinction between those aspects of their code that were significant for sequence structure from those that represented the characteristics of a particular term. In this way too, the dynamic algebra of the programming code would — and did — become a means for them to think about the relationships in the sequence.